Flexible Teamwork in Behavior-Based Robots

A key challenge in deploying teams of robots in real-world applications is to automate the control of teamwork, such that the designer can focus on the taskwork. Existing teamwork architectures seeking to address this challenge are monolithic, in that they commit to interaction protocols at the architectural level, and do not allow the designer to mix and match protocols for a given task. We present BITE, a behaviorbased teamwork architecture that automates collaboration in physical robots, in a distributed fashion. BITE separates task behaviors that control a robot’s interaction with its task, from interaction behaviors that control a robot’s interaction with its teammates. This distinction provides for flexibility and modularity in terms of the interactions used by teammates to collaborate effectively. It also allows BITE to synthesize and significantly extend existing teamwork architectures. BITE also incorporates key lessons learned in applying multi-agent teamwork architectures in physical robot teams. We present empirical results from experiments with teams of Sony AIBO robots executing BITE, and discuss the lessons learned. Introduction Teamwork in autonomous robots is fast gaining interest in academic and industrial research groups, motivated by realworld applications for multi-robot teams. To facilitate robust and speedy deployment of such teams, teamwork architectures are increasingly used to automate the interactions between team-members, such as synchronized task execution (Pynadath & Tambe 2003), and task allocation (Parker 1998; Dias & Stentz 2000; Gerkey & Matarić 2004; Vu et al. 2003). This allows the designer to focus on developing the taskwork, rather than the teamwork. However, existing architectures leave important challenges open when applied to multi-robot teams. First, existing robot teamwork architectures do not provide both synchronized task execution and dynamic task allocation in the same architecture. Thus the team’s developer must make a choice as to whether synchronization or allocation is more important. Second, existing architectures are monolithic, in the sense that they commit to a single interaction protocol Gal Kaminka is also affiliated with CMU. This research was supported in part by BSF grant #2002401, and by Israel’s Ministry of Science infrastructure grant # 3-942. Copyright c 2005, American Association for Artificial Intelligence (www.aaai.org). All rights reserved. for implementing each service, e.g., confirm-request for synchronization (Pynadath & Tambe 2003). Yet, as we show in our experiments below, the ability to flexibly mix and match protocols can critically impact task performance. This paper argues that flexible teamwork must rely on a micro-kernel approach, in which different coordination protocols (such as synchronization and allocation) can be interchanged, even within the same task. For example, flexible teamwork must allow for robots to sometimes allocate tasks using market approaches (Dias & Stentz 2000), and sometimes based on robustness concerns (Parker 1998). To make this argument concrete, this paper presents BITE (Bar Ilan Teamwork Engine), a novel behavior-based teamwork architecture targeting physical robot applications. Similarly to previous architectures (Pynadath & Tambe 2003; Vu et al. 2003), BITE maintains an organization hierarchy and a task/sub-task behavior graph to manage teamwork. However, in addition, BITE maintains a novel third structure, a library of hierarchically linked social interaction behaviors implementing interaction protocols for synchronization and task allocation. These are (re)used interchangeably, to automatically coordinate team-members’ selection of task behaviors. We describe our experience in using BITE with teams of Sony AIBO robots. BITE’s structure gives rise to novel separation of social interaction from task-oriented control, and provides uniform access to interchangeable interaction protocols. We show in multiple experiments, that this separation and is a significant contribution, in the sense that it accounts for non-trivial effects on team performance, and facilitates robustness. Motivation and Background Our primary motivation is to explore architectural mechanisms for flexible teamwork. Teamwork literature reveals common teamwork primitives: sub-task synchronization (getting agents to temporally coordinate task execution), and task allocation (getting agents to divide up the subtasks between them). While previous work has addressed both of these important aspects of teamwork, it mostly focuses on one aspect at a time. The TEAMCORE architecture (Pynadath & Tambe 2003) uses decision-theoretic communications in synchronizing the selection and termination of hierarchical behaviors, and uses task re-allocation behaviors that could be triggered based on catastrophic failures. The ALLIANCE behaviorbased architecture (Parker 1998) focused on robustness, by allowing robots to dynamically re-allocate themselves to tasks, based on failures in themselves in their teammates. Both of these architectures have been demonstrated to work in multiple domains. TEAMCORE provides synchronization and some allocation services. ALLIANCE is offers dynamic task allocation, but does not explicitly synchronize robots as they jointly take on tasks. Both rely on fixed interaction protocols, and in that they are monolithic: They do not allow flexibility in choosing the interaction protocols underlying synchronization and allocation. Within robotics work, a number of monolithic marketbased approaches have been proposed for task allocation. Dias and Stentz (2000) discuss the use of markets to allow robots to bid for tasks in spatial sensing domain. Gerkey and Matarić (2004) explored multi-robot task allocation. We believe that a teamwork architecture (1) should provide integrated synchronization and allocation; and (2) should be non-monolithic, in that different synchronization and allocation protocols could be mixed and matched, even within the same task. SCORE (Vu et al. 2003) demonstrated the usefulness of using multiple protocols depending on execution context. However, SCORE only allowed flexible allocation; its synchronization mechanism is communicationintensive and prone to failures. BITE seeks to fulfill this vision of flexible teamwork in robot teams. It can provide many, though not all, of the capabilities of previous investigations, but teases apart coordination, control, and communications. None of the previous investigations allows such separation, which we achieve through the maintenance of separate social interaction behaviors. Thus for instance, it is possible in BITE to switch between multiple synchronization methods, to dynamically re-allocate robots to tasks in more than one way, and to manage proactive communications. However, BITE still lacks STEAM and ALLIANCE’s failure-recovery facilities. BITE: Structures and Control BITE uses hierarchical behaviors as the basis for its control. To these, it adds two additional structures: A set of social interaction behaviors, and an associated team-hierarchy. A single control algorithm uses these structures to automate control and communications of a team of robots Control Structures The first of the three structures specifies the sequential and hierarchical relationships between task-oriented behaviors. The task behavior graph is an augmented connected graph tuple , where is a set of task-achieving behaviors (as vertices), sets of directed edges between behaviors ( ), and a behavior in which execution begins. Each behavior in may have preconditions which enable its selection (the robot can select between enabled behaviors), and termination conditions that determine when its execution must be stopped. is a set of sequential edges, which specify temporal order of execution of behaviors. A sequential edge from to specifies that must be executed before executing . A path along sequential edges, i.e., a valid sequence of behaviors, is called an execution chain. is a set of vertical task-decomposition edges, which allow a single higher-level behavior to be broken down into execution chains containing multiple lowerlevel behaviors. At any given moment, the robot executes a complete path—root-to-leaf—through the behavior graph. Sequential edges may form circles, but vertical edges cannot. Thus behaviors can be repeated by choice, but cannot be their own ancestors. Previous teamwork architectures rely on similar behavior graphs (with some variations) to represent and manage task control knowledge (Parker 1998; Pynadath & Tambe 2003). A common theme is for each robot to have its own copy of the behavior graph. Behaviors whose execution is to be coordinated in some fashion (henceforth, team behaviors) are tagged in advance by the designer. The teamwork architecture in question automatically take actions to select and de-select these in different robots, when appropriate. Figure 1-b shows an example of a simple behavior graph, constructed for multi-robot formation maintenance tasks. Here, there are two formation behaviors—triangle formation and line formation. Execution begins with triangle formation, and can (under specific conditions) switch to the line formation. Both formations use one behavior–search– in which robots visually search for their peers and their own relative locations. Then, the robots choose between the walk behavior (which implements walking in triangle) or the linewalk behavior in which robots follow each other in a line. The above behaviors are tagged as team behaviors, and require two important teamwork capabilities: synchronization (to make sure all robots select the same behavior, and start/end walk or linewalk together), and allocation (to make sure only a single leader for the formation is chosen, the followers are assigned different relative positions, etc.). To allow BITE to automate synchronization, we impose a constraint on the semantics of multiple outgoing edges. Two outgoing sequential edges !